fix(api): explicit scalar cwe stays primary when cwes list is also supplied#15305
Merged
Maffooch merged 1 commit intoJul 23, 2026
Merged
Conversation
…pplied PR DefectDojo#15143 added multiple-CWE support (cwes object list, writable on create and update). When a request supplied BOTH the scalar cwe and a cwes list, cwes[0] unconditionally overwrote the explicit scalar - the more specific input lost. Precedence now mirrors the vulnerability_ids->cve pattern: an explicit scalar cwe in the request stays the primary and every cwes entry is treated as an extra row (save_cwes dedupes the overlap); without a scalar, cwes[0] becomes the primary and is mirrored into the scalar. Detection uses initial_data presence - the established pattern in this serializer (FindingTemplateSerializer). Behavior change only for the unreleased cwes field when both inputs appear in one request; no released consumer can depend on the old behavior. Wire shape unchanged. +8 API tests: precedence on create/update, cwes-only primary promotion, replace, omission-untouched, explicit-empty semantics, read-back shape.
blakeaowens
approved these changes
Jul 22, 2026
Maffooch
approved these changes
Jul 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes a precedence bug in the (unreleased, dev-only) multiple-CWE write support that #15143 added to the finding API, and hardens its test coverage.
cweand acweslist,cwes[0]unconditionally overwrote the explicit scalar — the more specific input lost, on both create and update.vulnerability_ids→cvepattern — an explicit scalarcwein the request stays the primary and everycwesentry is persisted as an extraFinding_CWErow (save_cwesdedupes any overlap); when no scalar is supplied,cwes[0]becomes the primary and is mirrored into the scalar. Detection usesinitial_datapresence, the pattern this serializer already uses elsewhere.cwesremains the[{"cwe": "CWE-n"}]object list; no fields renamed, no response changes). The behavior change affects only the not-yet-releasedcwesfield and only requests carrying both inputs at once, so no released consumer can depend on the old behavior.unittests/test_finding_cwe.py— precedence on create and update (both proven failing before the fix), cwes-only primary promotion, list replacement, omission leaves rows untouched, explicit-empty clears extras (with and without a scalar), and a read-back wire-shape guard.spectacular --fail-on-warnpasses.cwechange withcwesomitted does not resync the existingFinding_CWErows, which can leave a stale primary row. Not enshrined in a test, so it stays cheap to change if desired.